chore(deps): bump pydantic-core from 2.46.4 to 2.47.0 - #84

…ependabot alerts (#110)

main currently cannot install. #84 bumped `pydantic-core` to 2.47.0 in
requirements.txt, but `pydantic==2.13.4` requires `pydantic-core==2.46.4`
exactly, so `pip install -r requirements.txt` fails outright:

    Because pydantic==2.13.4 depends on pydantic-core==2.46.4 [...]
    and because you require pydantic-core==2.47.0, we can conclude that
    your requirements are unsatisfiable.

Databricks Apps installs from requirements.txt, so every deploy from main is
broken until this lands. Root cause: requirements.txt is *compiled* from
pyproject.toml, and editing one pin in it without re-running the resolver can
produce a file that no longer resolves. GitHub reported the PR as MERGEABLE and
the unit suite passed, because neither installs requirements.txt.

Security floors added to pyproject.toml (so the resolver honours them rather
than patching the compiled output), clearing 19 of 20 open alerts:

  gitpython         3.1.50 -> 3.1.57   12 alerts
  mcp               1.27.1 -> 1.29.0    3 alerts
  pyasn1            0.6.3  -> 0.6.4     3 alerts
  pydantic-settings 2.14.1 -> 2.14.2    1 alert

The 20th alert (GHSA-g6cj-pr64-35w5, cryptography < 50.0.0) is deliberately
left open. 50.0.0 is newer than the `exclude-newer` supply-chain cooldown, so
raising the floor makes the project unresolvable, and bumping the cooldown to
reach it isn't worth it: the advisory is a Bleichenbacher oracle in PKCS#7
EnvelopedData decryption, and nothing here touches that path (`git grep -i
pkcs7` is empty) — cryptography is present for TLS and JWT signing via
google-auth/pyjwt. Bypassing a cooldown that exists to catch compromised fresh
releases, in order to dodge an unreachable CVE, trades a real risk for a
theoretical one. The floor comment records the exact condition for bumping it.

Also teaches Dependabot to leave exactly-pinned transitive packages alone
(pydantic-core, importlib-metadata, protobuf). The latter two caused this same
class of breakage in #3 and #60.

Verified: `uv pip install -r requirements.txt` resolves, requirements.lock
regenerates, all 13 app modules import, 501 tests pass.

#120)

CI has never run the test suite on this repo. The Tests workflow has exactly one
run in its history — a manual workflow_dispatch in May — and that run has zero
jobs. Dependency Audit and Update Lockfile have never produced a run at all.

Cause: all three target `databrickslabs-protected-runner-group`. That group is
granted per-repo across the org (ucx, dqx, dlt-meta and others use it
successfully) and this repo was never granted it, so jobs targeting it are
never scheduled — silently, with no failure anywhere to notice.

Consequences already observed:

- #84 bumped pydantic-core to 2.47.0 while pydantic==2.13.4 pins
  pydantic-core==2.46.4 exactly. requirements.txt became unsatisfiable, so
  every Databricks Apps deploy from main failed until #110 repaired it. GitHub
  reported the PR MERGEABLE; nothing installed requirements.txt.
- #115 and #116 were the same failure and were caught only by resolving them
  by hand.
- requirements.lock had drifted from requirements.txt, because Update Lockfile
  never ran. Regenerated here.

## Runners

test.yml, dependency-audit.yml and update-lockfile.yml move to ubuntu-latest.
None of them need org secrets — the first two are read-only, and the third uses
only the repo-scoped GITHUB_TOKEN. GitHub-hosted runners are free for public
repos. release.yml is left on the protected group: it signs release artifacts,
so it deserves a deliberate decision rather than a drive-by change (it also
means releases stay blocked until the repo is granted the group — noted in the
PR).

## New gates, each tied to a failure that actually happened

1. requirements.txt must be installable — catches the #84/#115/#116 class.
2. requirements.lock must match requirements.txt — catches the drift above.
3. App modules must import — 13 modules whose failure takes the app down at
   boot, most with no direct unit test.
4. A floor on tests that actually ran — a suite reporting "all skipped" passes
   vacuously, which is exactly what #106 fixed (465 skipped).

## Two bugs found while verifying the workflow locally

- tests/e2e/conftest.py raised an uncaught FileNotFoundError when the
  databricks CLI is absent. That surfaces as a pytest INTERNALERROR which kills
  the entire session — so this workflow would have failed on its first run on a
  hosted runner, where the CLI isn't installed. A missing CLI is now treated as
  "prerequisite absent" and skips.
- tests/integration is excluded from the PR gate. It gates on Docker, and
  Docker *is* present on ubuntu-latest, so it would really run: building an
  apps-like image and executing the full setup pipeline. Confirmed locally that
  including it produces failures. It stays runnable on demand.

## Verification

Every step was run locally, including with PATH stripped of the databricks CLI
to simulate a hosted runner: 535 passed, 3 skipped. Each of the four gates was
then confirmed to fail when its bug is reintroduced — the #84 pin, a truncated
lockfile, and the #106 whole-session skip.

* feat: add _get_session_process() helper for child process detection


* feat: add GET /api/sessions — list active sessions with process detection


* feat: add POST /api/session/attach — reattach with buffer replay

* fix: clean up session dict immediately on PTY EOF (exit = kill)

* feat: detach on tab close — remove sendBeacon kill from cleanupPane


* feat: session picker with reattach, kill, and new session support



* fix: session picker only on page load, not on split/new tab

Split pane and new tab (user-initiated) always create a fresh session.
Session picker only runs for the first pane on initial page load.

* fix: replace fake clickable buttons with keyboard-only picker UI

* fix: send resize after reattach so PTY redraws correctly

* fix: skip splash on reattach, add d{N} kill, sessions toolbar button

Three fixes:
- Reattach skips CoDA splash and duplicate resize (root cause of blank
  screen after picker selection — splash was clearing the replayed buffer)
- Picker supports d{N} to kill individual sessions (e.g. d2 kills #2)
- Sessions button (☰) in toolbar opens picker in active pane anytime

* feat: Ctrl+Shift+S opens session picker from any terminal

* feat: sessions carry tab label — picker shows name instead of just process

* fix: show (open) tag and block attaching to already-open sessions

Bumps [pydantic-core](https://github.com/pydantic/pydantic) from 2.46.4 to 2.47.0.
- [Release notes](https://github.com/pydantic/pydantic/releases)
- [Changelog](https://github.com/pydantic/pydantic/blob/main/HISTORY.md)
- [Commits](https://github.com/pydantic/pydantic/commits)

---
updated-dependencies:
- dependency-name: pydantic-core
  dependency-version: 2.47.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
...

Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

…ependabot alerts (#110)

main currently cannot install. #84 bumped `pydantic-core` to 2.47.0 in
requirements.txt, but `pydantic==2.13.4` requires `pydantic-core==2.46.4`
exactly, so `pip install -r requirements.txt` fails outright:

    Because pydantic==2.13.4 depends on pydantic-core==2.46.4 [...]
    and because you require pydantic-core==2.47.0, we can conclude that
    your requirements are unsatisfiable.

Databricks Apps installs from requirements.txt, so every deploy from main is
broken until this lands. Root cause: requirements.txt is *compiled* from
pyproject.toml, and editing one pin in it without re-running the resolver can
produce a file that no longer resolves. GitHub reported the PR as MERGEABLE and
the unit suite passed, because neither installs requirements.txt.

Security floors added to pyproject.toml (so the resolver honours them rather
than patching the compiled output), clearing 19 of 20 open alerts:

  gitpython         3.1.50 -> 3.1.57   12 alerts
  mcp               1.27.1 -> 1.29.0    3 alerts
  pyasn1            0.6.3  -> 0.6.4     3 alerts
  pydantic-settings 2.14.1 -> 2.14.2    1 alert

The 20th alert (GHSA-g6cj-pr64-35w5, cryptography < 50.0.0) is deliberately
left open. 50.0.0 is newer than the `exclude-newer` supply-chain cooldown, so
raising the floor makes the project unresolvable, and bumping the cooldown to
reach it isn't worth it: the advisory is a Bleichenbacher oracle in PKCS#7
EnvelopedData decryption, and nothing here touches that path (`git grep -i
pkcs7` is empty) — cryptography is present for TLS and JWT signing via
google-auth/pyjwt. Bypassing a cooldown that exists to catch compromised fresh
releases, in order to dodge an unreachable CVE, trades a real risk for a
theoretical one. The floor comment records the exact condition for bumping it.

Also teaches Dependabot to leave exactly-pinned transitive packages alone
(pydantic-core, importlib-metadata, protobuf). The latter two caused this same
class of breakage in #3 and #60.

Verified: `uv pip install -r requirements.txt` resolves, requirements.lock
regenerates, all 13 app modules import, 501 tests pass.

#120)

CI has never run the test suite on this repo. The Tests workflow has exactly one
run in its history — a manual workflow_dispatch in May — and that run has zero
jobs. Dependency Audit and Update Lockfile have never produced a run at all.

Cause: all three target `databrickslabs-protected-runner-group`. That group is
granted per-repo across the org (ucx, dqx, dlt-meta and others use it
successfully) and this repo was never granted it, so jobs targeting it are
never scheduled — silently, with no failure anywhere to notice.

Consequences already observed:

- #84 bumped pydantic-core to 2.47.0 while pydantic==2.13.4 pins
  pydantic-core==2.46.4 exactly. requirements.txt became unsatisfiable, so
  every Databricks Apps deploy from main failed until #110 repaired it. GitHub
  reported the PR MERGEABLE; nothing installed requirements.txt.
- #115 and #116 were the same failure and were caught only by resolving them
  by hand.
- requirements.lock had drifted from requirements.txt, because Update Lockfile
  never ran. Regenerated here.

## Runners

test.yml, dependency-audit.yml and update-lockfile.yml move to ubuntu-latest.
None of them need org secrets — the first two are read-only, and the third uses
only the repo-scoped GITHUB_TOKEN. GitHub-hosted runners are free for public
repos. release.yml is left on the protected group: it signs release artifacts,
so it deserves a deliberate decision rather than a drive-by change (it also
means releases stay blocked until the repo is granted the group — noted in the
PR).

## New gates, each tied to a failure that actually happened

1. requirements.txt must be installable — catches the #84/#115/#116 class.
2. requirements.lock must match requirements.txt — catches the drift above.
3. App modules must import — 13 modules whose failure takes the app down at
   boot, most with no direct unit test.
4. A floor on tests that actually ran — a suite reporting "all skipped" passes
   vacuously, which is exactly what #106 fixed (465 skipped).

## Two bugs found while verifying the workflow locally

- tests/e2e/conftest.py raised an uncaught FileNotFoundError when the
  databricks CLI is absent. That surfaces as a pytest INTERNALERROR which kills
  the entire session — so this workflow would have failed on its first run on a
  hosted runner, where the CLI isn't installed. A missing CLI is now treated as
  "prerequisite absent" and skips.
- tests/integration is excluded from the PR gate. It gates on Docker, and
  Docker *is* present on ubuntu-latest, so it would really run: building an
  apps-like image and executing the full setup pipeline. Confirmed locally that
  including it produces failures. It stays runnable on demand.

## Verification

Every step was run locally, including with PATH stripped of the databricks CLI
to simulate a hosted runner: 535 passed, 3 skipped. Each of the four gates was
then confirmed to fail when its bug is reintroduced — the #84 pin, a truncated
lockfile, and the #106 whole-session skip.